Order chronicle process and method

ABSTRACT

A process for chronicling a portion of an electronic market includes a record process for recording an activity relating to a security interest in an order book in main memory of a computer system and another record process for recording the activity in a persistent store.

RELATED APPLICATIONS

[0001] This application claims the priority of U.S. Provisional PatentApplication No. 60/385,988, entitled “Security Processor”, and filed onJun. 5, 2002 and to U.S. Provisional Patent Application No. 60/385,979,entitled “Supermontage Architecture”, and filed on Jun. 5, 2002.

BACKGROUND

[0002] This invention relates to electronic securities trading, and theprocessing and displaying of information relating to electronicsecurities trading.

[0003] Electronic equity markets, such as The Nasdaq Stock Market™collect, aggregate, and display pre-trade information to market makers.In The Nasdaq Stock Market™, for example, this pre-trade information cantake the form of a quote that represents a single or an aggregate ofsame-priced principal or agency orders. A market, such as The NasdaqStock Market™ also provides trading platforms through which marketparticipants may trade securities in the marketplace.

SUMMARY

[0004] According to an aspect of this invention, a process forchronicling a portion of an electronic market includes a record processfor recording an activity relating to a security interest in an orderbook in main memory of a computer system and another record process forrecording the activity in a persistent store.

[0005] According to a further aspect of the invention, a method forchronicling a portion of an electronic market includes recording anactivity relating to a security interest in an order book in main memoryof a computer system and recording the activity in a persistent store.

[0006] According to a further aspect of the invention, a computerprogram product residing on a computer readable medium for chronicling aportion of an electronic market includes instructions for causing acomputer to record an activity relating to a security interest in anorder book in main memory of a computer system, and to record theactivity in a persistent store.

[0007] One or more of the following features may also be included.

[0008] The main memory may be random access memory. The main memory maybe a cache. The first activity may be recorded in the main memory and inthe persistent store prior to recording a second activity. The firstactivity may be recorded in the order book and in the persistent storewithin a number of clock cycles. The main memory may be separate fromthe persistent store. The persistent store may be a sequential storagedevice. The persistent store may be a hard disk drive. The firstactivity may include matching a security transaction against a portionof the security interest. The first activity may include executing asecurity transaction against a portion of the security interest. Thepersistent store may be used to rebuild the order book. The state of theorder book may represent the existing market at the time of the firstactivity.

[0009] One or more advantages can be provided from the above. Bystoring, for example, received orders, quotes, or other securityinformation in an order book residing in random access memory,processing time decreases while throughput substantially increases.Further, by recording the securities activities in a hard disk filenearly simultaneously with executing the activities, a complete recordof the executed activities is created. Thus, the order book may bequickly rebuilt from the security activities recorded in the hard diskfile. Additionally, by storing the activities in the hard disk file, therebuilt order book will continue to represent the existing state of themarket after an emergency such as a system malfunction. By providingreliable backup to the securities information stored in the randomaccess memory resident order book, a trading slow down due to anemergency is reduced.

DESCRIPTION OF DRAWINGS

[0010]FIG. 1 is a block diagram of a server.

[0011]FIG. 2 is a block diagram of random access memory and a serverstorage.

[0012]FIG. 3 is a flow chart for using a random access memory residentorder book.

DETAILED DESCRIPTION

[0013] Referring to FIG. 1, a server 10 is shown that includes asecurities processor 12 that stores securities trade information in anorder book 14 that resides in random access memory 16 and an orderactivity log file 22 stored in server storage 56. The securitiesprocessor 12 is one portion of a computerized trading system, whichtrades securities electronically by processing one-sided or two-sidedtransactions entered by a user (e.g., a market participant). Userstypically access and use the computerized trading system via a computer,thus allowing the users to enter security trades themselves or throughprofessional traders/brokers. A central processing unit (CPU) 50processes the trades, received over network 52, by executinginstructions stored in an operating system (O/S) 54, along with otherinstructions, which are stored in the server storage 56. In someimplementations, the server storage 56 may be hard disk drive, a tapedrive, an optical drive, a redundant array of independent disks (RAID),a random access memory (RAM), or a read-only memory (ROM), for example,or other similar sequential access storage device or devices thatprovides a persistent store of the recorded information. Typically,server 10 is a multi-processing, fault-tolerant system that includesmultiple central processing units that each have a dedicated main memorysystem, in this implementation random access memory 16, or share acommon main memory pool. While being executed by the central processingunit(s) of server 10, multiple instantiations of securities processor 12may reside in the main memory system of server 10. Further, theprocesses and subroutines of securities processor 12 may also be presentin various levels of cache memory incorporated into server 10.

[0014] Referring to FIG. 2, the server storage 56 and the securitiesprocessor 12 residing in the random access memory 16 is shown. Forexample, to perform a trade for a particular security, a user enters anorder into the computerized trading system that is received and directedto the securities processor 12 assigned to the particular security. Insome implementations, the securities processor 12 may be assigned to twoor more securities in order to distribute the volume of securitiestrading over a number of securities processors (not shown). In otherimplementations the securities processor 12 may be assigned to oneheavily traded, high volume security to reduce trading volume of thatsecurity on other securities processors.

[0015] The securities processor 12 may be assigned to one particularsecurity and store related security trading interest in the order book14 residing in the random access memory 16 of that securities processor12. By random access memory is meant main memory or alternatively one ormore levels of cache memory. In some implementations a matching processmay load portions of the order book into a level of cache memory fromthe main memory. Alternatively, the securities processor 12 may beassigned to multiple securities and correspondingly, the order book 14residing in random access memory 16 of that securities processor storesthe trading interests of those multiple securities. In someimplementations, to store interests for multiple securities, the orderbook 14 in random access memory 16 may be partitioned into multiplesections, dimensions, or files to store the interests assigned to thesecurities processor 12. Here the order book 14 resides within theexecution space of the random access memory 16 that has the matchingprocess 62. However, in some implementations the order book 14 residesin an execution space of the random access memory 16 that is separatefrom another execution space having the matching process 62. Also, theorder book 14 is exclusively accessible by the matching process 62regardless whether or not both reside in the same execution space of therandom access memory 16.

[0016] In addition to the support for a horizontally scalablearchitecture, the in memory order book 14 provides for reliabletransaction processing at extremely high rates for an individualsecurity. The internal state of the securities processor 12 is adjustedby processing incoming transactions in strict first-in, first-out serialsequence. The transaction rates capable for this approach exceeds thoserates provided by traditional file based approaches and provide areliable approach to use the order book 14 in random access memory 16 tohold the state of the book. By inserting, updating, and retrievingelements (records) from the in-memory order book 14 instead of a diskfile, throughput substantially increases. Also, logic for allocating andfreeing memory, maintaining lists and index tables associated with thein-memory order book 14 may be encapsulated random access memory 16.

[0017] In general, an order directed to the securities processor 12 isreceived by an order entry process 58 that performs cursory checkingfunctions (e.g., order eligibility, order syntax, etc.) on the receivedorder. If the received order fails one or more of the cursory functionsthe order is returned to the user, however, if the cursory functions arepassed, the received order is logged in a matching trigger 60. Thematching trigger 60 queues the received order along with, for example,other orders, quotes, deliveries, or supervisory commands that arereceived by the securities processor 12 for the security or securitiesassigned to the securities processor. Typically the received orderrepresents a new order for processing (e.g., match against open orders,add as new open orders, etc.) while the supervisory commands, forexample may cancel, modify, or execute other similar actions againstexisting orders stored in the order book 14 residing in random accessmemory 16.

[0018] Once queued into the matching trigger 60, the received order isheld in the matching trigger until pulled into a matching process 62 byan order management process 64. The matching process 62 matches portionsof the received order, i.e., executes and allocates the received ordersand stores the unmatched portion of the order stored in the order book14. After pulling the received order, which is at least partiallymarketable and has cleared initial validations, the matching process 62attempts to execute all or part of the received order with one or moreorders on the contra side of the order book 14. Upon pulling thereceived order, the matching process 62 checks and validates thereceived order (e.g., marketability check, apply short sale rule, etc.)with definite and unambiguous knowledge of the current state of themarket for the particular security. Some of the validations are specificto orders received while some validations are specific for quotesreceived by the securities processor 12 or are common to quotes andorders. In this particular example the security processor 12 received anorder and if the check or validation fails the received order isreturned to the user unexecuted.

[0019] One factor that is considered by the matching process 62 is thequantity of the received order. Matching the received order continuesuntil the entire received, marketable order is exhausted. In executingthe received order to the fullest extent, the display size of thereceived order, as well as the reserve size, if any, are combined andmatching process 62 continues to execute this combined quantity of thereceived order against contra side orders stored in the order book 14until exhaustion of the received order. To match against orders storedin the order book 14, the stored orders have an open status and are onthe opposite side of the market to that of the received order. Once thereceived order is completely exhausted, the matching process 62 iscomplete and the execution is reported to other processes internal andexternal to the securities processor 12.

[0020] Another factor concerning the matching process 62 is themarketability of the received order. After passing the previousvalidations during the order entry process 58, the matching process 62determines whether the received order is marketable. The received orderis marketable if the order is a limit or other type of priced order andthe received order's price locks or crosses the inside for theparticular security. For a received order which is a bid, the inside islocked or crossed if the bid price is higher than the current best(i.e., lowest) ask price; alternatively, for a received order which isan ask order, the inside is locked or crossed if the ask order price islower than the current best (i.e., highest) bid price. The receivedorder can also be marketable if it is a market type order.

[0021] Subsequently, if the order is marketable, further validations areperformed using current inside market prior to retrieving an orderstored in the order book 14 to match against. However, if after thereceived order is determined marketable and the subsequent matching ofthe received order against the orders retrieved from the order book 14,the inside spread changes which may result in the price of the receivedorder not locking or crossing the market that occurrence could end thematching process 62. Also, if the received order, or a portion of thereceived order, is not marketable or not fully executable, the remainderis added to the order book 14 for matching to a future order received bythe securities processor 12.

[0022] After the received order is determined marketable and subsequentvalidations based on current inside market are passed, the ordermanagement process 64 searches contra-side orders stored in the orderbook 14 that correspond to the particular security of the receivedorder. To search the orders stored in the order book 14, the ordermanagement process 64 may use parameters associated with the receivedorder. In some implementations, one parameter associated with thereceived order is the market participant ID that may be passed to theorder management process 64 as a search parameter. By searching with themarket participant ID, internalization, preferenced orders, or regularmatching may be performed by the order management process 64. A matchingpreference may also be associated with the received order. For example,the received order may specify a matching condition that causes thematching algorithm to match based on a price/time priority, aprice/fee/time priority, a price/size priority, or other preference.Also, the order management process 64 checks that a retrieved order fromthe order book 14 is available for matching (e.g., it is not in outage,etc.).

[0023] To initiate matching the received order, the matching process 62determines the total quantities that can be executed in the currentmatching cycle. The quantities are, for example, the total executabledisplay quantity for market participants non-unlisted trading privileges(non-UTPs), the total executable reserve quantity for non-UTPs, and thetotal executable UTP quantity. The UTP quantity is segregated in someembodiments because the UTPs are allocated against only after all thedisplay quantities and reserve quantities for non-UTPs at a particularprice level are exhausted. These quantities are used to determine howmuch quantity from the display and reserve size of a retrieved order maybe used in a match and whether a retrieved UTP order can be filled. Oncethe total executable quantities are defined, the orders for allocationretrieved from the order book 14 in accordance with the appropriateprioritization algorithm and the use of internalization.

[0024] The order management process 64 retrieves the next order from theorder book 14 and determines if the retrieved order meets the executionpreference and requirements of the current match. For example, if areceived order is specified with a prioritization preference ofprice/fee/time priority, and order management process 64 retrieves anorder from the order book 14 with fees, then this retrieved order isskipped. The order management process 64 continues to look for orders ata price level until an order that does not have access fees is found. Ifthe order of this type is not found, the order management process 64starts over and retrieves orders from the order book 14 that chargefees. After all orders residing in the order book 14, at a price levelthat meet the specified requirements for the match are exhausted, thematching cycle continues at the next price level provided the market isstill crossed.

[0025] To execute a match between the received order and the orderretrieved from the order book 14, the order management process 64determines if the match, for example, is an automatic execution, an oddlot, or a delivery and assigns the appropriate execution type to theexecution. After matching the received order, the order managementprocess 64 updates the retrieved order in the order book 14. Forexample, the retrieved order may be completely exhausted and updated as‘executed’ or, in another example, the retrieved order may have beenpartially executed and the remainder of the order is stored in the orderbook 14 with an open status. Also, during the matching of the receivedorder, as the displayed size is exhausted, orders can be replenishedfrom the reserve size. As portions of the received orders are matched byorders on the order book 14, the order management process 64 updates theorder book 14 to reflect the matches. The order management process 64also checks if the received order should be refreshed. If the order isrefreshed and the market is still crossed, the order management process64 continues matching. Otherwise, the order management process 64completes by reporting the portion executed to other processes includedin the securities processor 12 and external 68 to the securitiesprocessor.

[0026] In some implementations matching process 62 includes a loopingfunction that is triggered when the received order is identified asbeing executable. The matching process 62 would attempt to match aportion of the received order and continues matching the received orderas long as the received quantity is greater than zero and the market isstill crossed. If either of these conditions fails, then the matchingprocess 62 is completed and executions are reported to processesinternal and external to the securities processor 12.

[0027] During operations of the securities processor 12, the order book14 is only accessible by the matching process 62, which serves as aninterface and the single point of access to the order book. Byrestricting access of the order book 14 to the matching process 62,other processes included in or related to the securities processor 12 dono interfere with operations of the order book 14. For example, in somecomputerized trading systems an order book may, for example, be scannedto provide securities information to users during the same time periodas the orders are retrieved from the order book to match a receivedorder. Interruptions, such as this, which allow access and sharing ofthe order book between the matching process 62 and other lower priorityprocesses slows the matching process and reduces trading efficiency.Also, by restricting access to the order book 14, securities informationthroughput significantly increases. Thus, by isolating the order book 14to interact with only the matching process 62, matching speed andefficiency increases.

[0028] Besides receiving and processing an order, other activitiesrelated to the security or securities assigned to the securitiesprocessor 12 may be received. For example, a quote update may bereceived by the securities processor 12 and pulled from the matchingtrigger 60 by the matching process 62 for adding the quote in the orderbook 14 or preparing the quote for matching. If the received quote doesnot lock or cross the market, the order book 14 is updated by replacingan existing quote or adding the received quote as an initial quote. Inanother example, a two-sided quote may be received by the securityprocessor 12 and pulled from the matching trigger 60 by the matchingprocess 62. The side of the quote that does not lock or cross the marketupdates an existing quote or adds the quote as an initially receivedquote in the order book 14. The quote side that locks or crosses theinside is matched by the matching process 62 and any remainder will beadded to the order book 14. Also, the marketable side of a receivedquote is removed from the order book 14 and replaced by any remainderafter matching. A received quote may also be a relative update (e.g., asize increment or a size decrement) in which the matching process 62adjusts the existing quote in the order book 14 for the relative sizechanges.

[0029] Supervisory commands (e.g., closing positions for a specificmarket participant, blocking a market participant's positions from beingopened during the market opening process, purging a market participant'sorders, or other similar command, etc.) may also be received by thesecurities processor 12 and pulled from the matching trigger 60 by thematching process 62. However, supervisory commands transactions arecomplete, inclusive, and are implemented as modular plug-in components.

[0030] After matching, for example, the received order, or a portion ofa received order, against one or more orders in the order book 14 andprior to pulling the next activity order from the matching trigger 60,the order management process 64 reports the matching of the receivedorder, or a portion of the received order, to the order activity logfile 22 located in the server storage 56. Since the order activity logfile 22 receives the report from the order management process 64 priorto pulling the next order from the order trigger 60, the order activitylog file has the current status of the order book 14, and thus thecurrent status of the market before any further processing. Thus, if anunforeseen catastrophe occurs, such as losing the information containedin the order book 14, the order book may be rebuilt based on theinformation backed-up in order activity log file 22.

[0031] Besides reporting the execution of the received order or aportion of the received order, the order management process 64 mayreport, for example, executing a delivery order, executing an odd-lotorder, adding a quote, canceling an order, canceling/replacing an order,purging an order, updating the order book 14 to reflect executions oradding an unmatched received order or a portion of the received order,or other similar activity associated to the securities processor 12.Also, in some implementations the order activity log file 22 may, forexample, be a data file, a database, or other data storage structureresiding in server storage 56. Once stored in the order activity logfile 22, the activities may be disseminated, for example, to tradeparticipants, an Automated Confirmation Transaction (ACT) system, otherinterested parties, or processes internal or external to the securitiesprocessor 12.

[0032] In particular, one process associated with the securitiesprocessor 12, which accesses the activities stored in the order activitylog file 22 is an order file builder process 70. The order file builderprocess 70 constructs an order file 72 that provides near real-timedisaster recovery of the order book 14 for a number of potential failurescenarios, as well as the contingent redeployment of activity processingto secondary securities processors (not shown). Each potential failurepoint in the trading system is supported by a level of redundancy,ranging from immediate system-level backup to delayed manual takeover.In the interest of rapid recovery for virtually all failures, a degreeof automatic processing is allowed, but in general manual interventionis always an option. At lower failure levels, for example the failure ofthe securities processor 12, the securities processor is attempted to berestarted. As failure severity increases, such as the loss of the CPU 50(shown in FIG. 1), the level of automation employed decreases.Ultimately, the most serious catastrophic failure, such as a loss of theentire server 12, may permit little automatic recovery.

[0033] To provide disaster recovery, the order file builder process 70builds and maintains the order file 72 by retrieving the activitiesstored in the order activity log file 22. In some implementations, theorder file 72 is stored on the server storage 56 and has the latestupdates for open orders or orders with a special status (e.g., themarket participant requests closing their positions due to equipmenttrouble, a display and reserve quantity are zero but the deliveryquantity is greater that zero, etc.). While the order file builderprocess 70 stores activities related to updating the order book 14,activities not needed for reconstructing the order book 14, such asexecuted or canceling orders, are filtered from the material stored inthe order file 72. By storing these activities, the order file 72provides the current status of the security interests residing in theorder book 14 to provide fast recovery after in the event of amalfunction of the securities processor 12 or reassigning one or moresecurities to another security processor.

[0034] As mentioned, since the order book 14 resides in random accessmemory 16 such as main memory and in some implementations is accessedonly by the matching process. In main memory information may be quicklystored on the order book as compared, for example, to order booksresiding in a magnetic medium (e.g., diskette, hard disk, etc.) whichtypically have much longer access times for storing and retrievingorders. Due to the fast accessibility of the random access memory 16,the order book 14 may be quickly rebuilt by retrieving informationstored in the order file 72, as compared to rebuilding order booksstored on a slower access hard disk or other magnetic medium.

[0035] Referring to FIG. 3, a procedure 100 for using an order bookresiding in random access memory is shown. The procedure 100 starts 102by pulling 104, for example, a particular security order from thematching trigger 60 (shown in FIG. 2) included in the securitiesprocessor 12 that is assigned to the security and determining 106 if aportion of the received order may be matched. If the procedure 100determines 106 that a portion of the received order can be matched, theprocedure 100 retrieves 110 a security trading interest on the oppositeside of the market from the order book 14 (also shown in FIG. 2) in therandom access memory 16 (also shown in FIG. 2). After retrieving 110 thesecurity interest from the order book 14, the procedure 100 executes 112the match between the portion of the received order and the retrievedsecurity interest from the order book and updates the order book toreflect the match. If the procedure 100 determines 106 that a portion ofreceived order can not be matched to any security interest residing onthe order book 14, the procedure 100 adds 108 the portion of thereceived order to the order book for potential matching with ordersreceived in the future. The order book 14 in memory is emptied at theend of each trading day, so orders received at the start of the nexttrading day are often added to the order book.

[0036] After executing 112 a portion of the received order or adding 108a portion of the received order to the order book 14, the procedure 100updates 114 the order activity log file 22 (also shown in FIG. 2) withan activity report relating to the received order. The order activitylog file 22 is updated prior to pulling the next received order, orother activity, from the matching trigger 60. By updating the order book14 and the order activity log file 22 prior to processing furtheractivities, a complete and current listing of the activities executed bythe securities processor 12 is contained in the order activity log file22. Thus, by recording the activities in both locations at nearly thesame time assures that the order book 14 may be rebuilt from theactivities stored in the order activity log file 22 if, for example, amalfunction disables the random access memory 16.

[0037] After updating 114 the order activity log file 22, the procedure100 returns to pull 104 the next received order, or other activity, fromthe matching trigger 60. Also after updating 114 the order activity logfile 22, the procedure 100 pulls 116 the newly entered activity reportfrom the order activity log file 22 while concurrently returning to pull104 the next received order. After pulling 116 the newly enteredactivity report from the order activity log file 22, the procedure 100determines 118 if the security interest corresponding to the activityreport has an open status. If the status is open, the order file 72(also shown in FIG. 2) is updated 120 with the activity and theprocedure 100 determines 122 if the trading day has ended. If thetrading day has ended, the procedure 100 stops 124, but if the tradingday has not ended, the procedure 100 returns to pulling 116 the nextreceived order, or other activity, entered into order activity log file22. However, if the status of the interest is not open, the order file72 is not updated since an interest with, for example, a closed statusis not relevant to rebuilding the order book 14 and the procedure 100determines 122 if the trading day has ended. Again, if the trading dayhas ended, the procedure stops 124, however, if the trading day has notended, the procedure 100 returns to pull 116 the next activity reportentered into the order activity log 22.

[0038] Although some implementations have been described, otherimplementations are also within the scope of the following claims.

[0039] In FIGS. 1-3, to assure rebuilding of the order book 14, areceived order, or a portion of a received order, is stored in the orderbook 14 and in the order activity log file 22 prior to pulling the nextactivity from the matching trigger 60. However, in some implementations,to assure rebuilding of the order book 14, the received order, or theportion of the received order, may be stored in the order book and inthe order activity log file 22 within a particular time period, aparticular number of clock cycles, or other similar timing process. Oncethe time period expires, the next activity may be pulled from thematching trigger 60 for processing by the matching process 62. Byrecording orders and other activities related to the order book 14 in arelatively short time period or for example, prior to processing thenext entry in the matching trigger 60, the order book may be quicklyrebuilt after numerous potential failure scenarios, as well ascontingent redeployment of processing to secondary securitiesprocessors.

[0040] The order book described herein is not limited to the softwareembodiment described above; it may find applicability in any computingor processing environment. The order book may be implemented inhardware, software, or a combination of the two. For example, the orderbook may be implemented using circuitry, such as one or more ofprogrammable logic (e.g., an ASIC), logic gates, a processor, and amemory.

[0041] The order book may be implemented in computer programs executingon programmable computers that each includes a processor and a storagemedium readable by the processor (including volatile and non-volatilememory and/or storage elements). Each such program may be implemented ina high-level procedural or object-oriented programming language tocommunicate with a computer system. However, the programs can beimplemented in assembly or machine language. The language may be acompiled or an interpreted language.

[0042] Each computer program may be stored on an article of manufacture,such as a storage medium (e.g., CD-ROM, hard disk, or magnetic diskette)or device (e.g., computer peripheral), that is readable by a general orspecial purpose programmable computer for configuring and operating thecomputer when the storage medium or device is read by the computer toperform the functions of the order book. The order book may also beimplemented as a machine-readable storage medium, configured with acomputer program, where, upon execution, instructions in the computerprogram cause a machine to operate to perform the functions of the orderbook described above.

[0043] Embodiments of the order book may be used in a variety ofapplications. Although the order book is not limited in this respect,the order book may be implemented with memory devices inmicrocontrollers, general purpose microprocessors, digital signalprocessors (DSPs), reduced instruction-set computing (RISC), and complexinstruction-set computing (CISC), among other electronic components.

[0044] Embodiments of the order book may also be implemented usingintegrated circuit blocks referred to as core memory, cache memory, orother types of memory that store electronic instructions to be executedby a microprocessor or store data that may be used in arithmeticoperations.

[0045] A number of embodiments of the invention have been described.Nevertheless, it will be understood that various modifications may bemade without departing from the spirit and scope of the invention.

What is claimed is:
 1. A process for chronicling a portion of anelectronic market comprises: a first record process for recording afirst activity relating to a security interest in an order book in mainmemory of a computer system; and a second record process for recordingthe first activity in a persistent store.
 2. The process of claim 1wherein the main memory is random access memory.
 3. The process of claim1 wherein the main memory is a cache.
 4. The process claim 1 wherein thefirst record process and the second record process record the firstactivity prior to recording a second activity.
 5. The process of claim 1wherein the first record process and the second record process recordthe first activity within a number of clock cycles.
 6. The process ofclaim 1 wherein the main memory is separate from the persistent store.7. The process of claim 1 wherein the persistent store is a sequentialaccess storage device.
 8. The process of claim 1 wherein the persistentstore is a hard disk drive.
 9. The process of claim 1 wherein the firstactivity includes matching a security transaction against a portion ofthe security interest.
 10. The process of claim 1 wherein the firstactivity includes executing a security transaction against a portion ofthe security interest.
 11. The process of claim 1 wherein the persistentstore is used to rebuild the order book.
 12. The process of claim 1wherein the state of the order book represents the existing market atthe time of the first activity.
 13. A method for chronicling a portionof an electronic market comprises: recording a first activity relatingto a security interest in an order book in main memory of a computersystem; and recording the first activity in a persistent store.
 14. Themethod of claim 13 wherein the main memory is random access memory. 15.The method of claim 14 wherein the main memory is a cache.
 16. Themethod of claim 13 wherein recording the first activity in the mainmemory and the persistent store is prior to recording a second activity.17. The method of claim 13 wherein the first activity is recorded in theorder book and persistent store within a number of clock cycles.
 18. Themethod of claim 13 wherein the random access memory is separate from thepersistent store.
 19. The method of claim 13 wherein the persistentstore is a sequential storage device.
 20. The method of claim 13 whereinthe persistent store is a hard disk drive.
 21. The method of claim 13wherein the first activity includes matching a security transactionagainst a portion of the security interest.
 22. The method of claim 13wherein the first activity includes executing a security transactionagainst a portion of the security interest.
 23. The method of claim 13wherein the persistent store is used to rebuild the order book.
 24. Themethod of claim 13 wherein the state of the order book represents theexisting market at the time of the first activity.
 25. A computerprogram product residing on a computer readable medium for chronicling aportion of an electronic market, comprises instructions for causing acomputer to: record a first activity relating to a security interest inan order book residing in main memory of a computer system; and recordthe first activity in a persistent store.
 26. The computer programproduct of claim 25 wherein the main memory is random access memory. 27.The computer program product of claim 25 wherein the main memory is acache.
 28. The computer program product of claim 25 wherein the firstactivity is recorded in the order book and the persistent store prior torecording a second activity.
 29. The computer program product of claim25 wherein the first activity is recorded within a number of clockcycles.
 30. The computer program product of claim 25 wherein the mainmemory is separate from the persistent store.
 31. The computer programproduct of claim 25 wherein the persistent store is a sequential storagedevice.
 32. The computer program product of claim 25 wherein thepersistent store is a hard disk drive.
 33. The computer program productof claim 25 wherein the first activity includes matching a securitytransaction against a portion of the security interest.
 34. The computerprogram product of claim 25 wherein the first activity includesexecuting a security transaction against a portion of the securityinterest.
 35. The computer program product of claim 25 wherein thepersistent store is used to rebuild the order book.
 36. The computerprogram product of claim 25 wherein the state of the order bookrepresents the existing market at the time of the first activity.